feat(metrics): record stream, queue and per-shard counters (#44) - #64

Several metric families were registered and exported but never written, so
they scraped as 0 forever. That is worse than being absent: a dashboard built
on flo_stream_append_records_total{topic="orders"} reads "no traffic" on a
stream actively taking writes.

Wired the write paths to the record* methods that already existed:

- stream append — recordAppend with the batch's logical record count, so a
  three-record batch counts three rather than one entry
- stream read — recordRead, likewise summing batch contents, and
  recordEmptyRead when a read returns nothing
- queue enqueue/dequeue — recordEnqueue, recordDequeue, recordEmptyDequeue
- per-shard — shardMetrics() had no callers at all, so every flo_shard_* row
  exported 0 while its global flo_* equivalent moved. The shard now resolves
  its metrics once at wire-up and records alongside the global counters.

registerStream and registerQueue already return the per-entity metrics and the
handlers already called them, discarding the result — so most of this is
capturing a pointer that was being thrown away.

## Tests

Four e2e tests asserting values, not presence: append three records and assert
the counter says 3, read them back and assert the read counter says 3, enqueue
two and dequeue and assert both, and assert per-shard commands are non-zero.
A parser pulls the numeric value out of the exposition line rather than
substring-matching, so a wrong number fails instead of passing on the metric
name appearing.

All four fail with the instrumentation stashed — verified rather than assumed,
since a metrics test that passes uninstrumented is exactly what let this hide.

## Not in this change

- processing and workflow: neither handler has a metrics_registry field and the
  shard does not wire one, so those need plumbing first rather than a call at
  an existing site. Both keep separate module-local metrics that are unrelated
  to the registry families.
- KVMetrics and TieredLogMetrics: exportPrometheus does not emit them and
  registerTieredLog has no callers. Whether to export or delete them is a
  product decision, not a mechanical fix.

The note in docs/deployment/clustering.mdx covers all of these families, so it
stays until the rest land.